1. Field of the Invention
The invention relates to computer busing systems, and more particularly to a method of and apparatus for detecting whether a device responds to a particular I/O or memory address asserted on that bus.
2. Description of the Related Art
The microcomputer industry has experienced tremendous growth over the last twenty years. From the days of its infancy when only a few interested "hackers" could fathom its quirks and nuances, the microcomputer has now evolved into a powerful business and personal tool found on virtually every office desk and in virtually every home.
The microcomputer's road to success has not been without its problems, however. While advances occur at an astounding pace, those advances must accommodate the standards found in the then existing base of microcomputer systems. This is known as upwards compatibility. To maintain such compatibility, the industry has seen one microcomputer standard laid on top of another, with a resulting hodgepodge of standards-within-standards that designers must maintain to allow existing users to upgrade their equipment. These multiple standards gradually shed their oldest layers, replacing them with new layers reflecting the state-of-the-art. In this way, only the very oldest microcomputer systems become obsolete.
One early idea to enhance microcomputer systems was the addition of hardware enhancing cards. These cards were generally plugged into a system bus to provide added functionality, such as telecommunications, disk storage, and improved video. These cards obviously had to conform to some standard. With the introduction of the IBM PC by International Business Machines Corp., and the later introduction of the PC/AT by IBM, the AT system bus soon became a de facto standard known as the Industry Standard Architecture bus, or the ISA bus. The AT bus accommodated both the 8-bit cards of the PC and newer 16-bit cards developed for the AT. Third-party manufacturers could economically design standard cards compatible with the wide variety of IBM PC and AT compatible microcomputer systems.
Further advances in microprocessor technology, however, pushed the ISA bus to its limits. For this reason, another "layer" was added to the ISA bus standard. This added layer became known as the Extended Industry Standard Architecture bus, or the EISA bus. Cards designed for the EISA bus had more pins, providing a wider data path for information to flow through the microcomputer system bus, analogous to adding lanes to a highway. The EISA bus also added more address lines to the standard, permitting more memory locations to be individually specified, much as would adding more digits to a phone number or a zip code.
One limitation of the ISA bus involved its method of handling I/O addressing. An address enable signal (AEN) was driven low by an ISA bus master to indicate to all of the cards that the currently asserted address was an I/O address or a memory address rather than a direct memory access (DMA) operation. But because AEN was asserted low to all cards, each card had to be physically configured to respond to a different range of I/O or memory addresses to avoid conflicts. This address differentiation was usually accomplished when installing the boards by setting microswitches on dual in-line packages (DIP) or by connecting jumpers on each board. Improperly setting these switches could result in conflicts on a read or write to a particular I/O or memory address and could even result in physical hardware damage.
While the ISA standard provided 16 bits of I/O addressing, in developing cards for PC-compatible computers, vendors often only used or decoded the lower 10 bits. Thus, to be fully compatible with the available cards, the I/O address space of the ISA bus effectively was only from 0 to 03FFh. Thus, a large portion of the I/O space was unusable.
The EISA bus standard has resolved this problem to some extent. The EISA bus definition provides for a conflict-free I/O address space for each slot. This is fully described in U.S. Pat. No. 4,999,805 and the EISA Specification, Version 3.1, which is Appendix 1 of U.S. Pat. No. 4,101,492, both of which are hereby incorporated by reference. The expansion board manufacturers include a configuration file with each EISA expansion board, and optionally, with switch programmable ISA products. A configuration utility program provided by the system manufacturer uses the information contained in the configuration files to determine a conflict-free configuration of the system resources. The configuration utility stores the configuration and initialization information into non-volatile memory and saves a backup copy on diskette. Details of this configuration process are provided in Ser. No. 07/293,315, entitled "Method and Apparatus for Configuration of Computer System and Circuit Boards," allowed on May 10, 1993, which is hereby incorporated by reference. The system ROM power up routines use the initialization information to initialize the system during power up, and device drivers use the configuration information to configure the expansion boards during operation.
However, this slot specific addressing does not help with ISA cards. Slot specific ISA card disabling can prevent such physical conflicts between two cards during their initialization. Briefly, a mask register is provided to mask off the AEN signal to selected slots. Details are provided in Ser. No. 08/145,400, entitled "Method of and Apparatus for Disabling Individual Slots on a Computer Bus," filed concurrently herewith, which is hereby incorporated by reference. The startup routines individually enable each ISA slot using a slot specific mask register. The startup routines then must determine what address spaces that card occupies. With the address space identified, this results in a signature and allows a determination of the particular card, to allow conflict checking and user setup. This is described in Ser. No. 08/145,338, entitled "Method of Determining the Configuration of Devices Installed on a Computer Bus," filed concurrently herewith, which is hereby incorporated by reference.
Further, the slot specific addressing is of no assistance with memory operations, as the EISA bus standard does not provide for slot specific memory spaces for ISA cards.
Once the startup routines enable a single ISA card, however, determining what addresses that card responds to is not trivial. Unlike EISA cards, ISA boards do not provide an identification register. Thus, the occupied address space of an ISA board must be determined in some other way.
In a typical system, a number of ISA boards may be installed, and the system software must then determine not only whether an ISA board is present in a particular slot, but also what type of board is installed in that slot. This involves determining what I/O read addresses a particular board occupies. First, using the slot specific disabling described in Ser. No. 08/145,400, a single slot on the ISA or EISA system bus is enabled. Then, all of the I/O and memory addresses are read. Each address that returns a value different from what an undriven data bus would return indicates that the enabled board has driven the data bus in response to a read from that particular I/O or memory address. To simplify this determination, the data bus is pulled up by resistors so that a read from a particular address returns 0FFh if the bus is not driven.
But just because a read results in 0FFh does not necessarily mean the bus is undriven. The particular board installed in the enabled slot may actually be driving an 0FFh on the data lines at that address in response to the read. Using standard systems, there is no way to determine this difference. Thus, a read value of 0FFh remains ambiguous and only non-0FFh locations are positively known. This will often leave a very large number of ambiguous locations, rendering identification of the board more difficult.
It would be desirable to determine each I/O or memory read address at which a particular board or device responds by driving the data bus, whether driving with the undriven value of the data bus or otherwise.